Does anyone know why the Mac OSX property list (pflist) file format is such a bastardization of XML?
December 29, 2004 12:36 PM Subscribe
Does anyone know why the Mac OSX property list (pflist) file format is such a bastardization of XML?
It looks like XML, except it doesn't form a proper tree.
It looks like XML, except it doesn't form a proper tree.
(as long as it nests - every opened element closes and no two elements "overlap" - then it is a tree. trees don't have to have all branches "teh same" in some way)
posted by andrew cooke at 12:45 PM on December 29, 2004
posted by andrew cooke at 12:45 PM on December 29, 2004
It's valid XML, but the DTD is general to key-value "property lists" rather than to the particular properties being listed. They're meant to be read to and from data structure with the Cocoa property-list API, not manipulated with XPath.
posted by nicwolff at 12:52 PM on December 29, 2004
posted by nicwolff at 12:52 PM on December 29, 2004
That link doesn't actually describe the format of a generic plist, it just gives descriptions of the keys in a specific plist. A better example of the XML is here. Also note the DTD which describes the format.
posted by xil at 12:52 PM on December 29, 2004
posted by xil at 12:52 PM on December 29, 2004
Good question. It does honestly look like something someone would design right after discovering XML, before they knew better.
posted by smackfu at 12:59 PM on December 29, 2004
posted by smackfu at 12:59 PM on December 29, 2004
Response by poster: Okay, I apologize. It is a valid document in the sense that it validates, but it isn't valid in the sense that it's not logically arranged. For example, from xil's link, you can see that a particular key/value pair is not separated by a sub-tree. The only way to find out when the current key/value pair ends is by the next node having another key.
Why go to so much work making it look like XML, only to arrange it completely illogically? They could have added one simple wrapper node to each key/value pair and it would have been perfect.
It's not easily parseable by man, nor machine.
posted by robinw at 1:01 PM on December 29, 2004
Why go to so much work making it look like XML, only to arrange it completely illogically? They could have added one simple wrapper node to each key/value pair and it would have been perfect.
It's not easily parseable by man, nor machine.
posted by robinw at 1:01 PM on December 29, 2004
I know some people are pissed that plist files rely on the order of the elements, not just that they exist. For example, an entry in a dictionary is:
incidentally, Sun went the verbose route with Servlets/JSP and the deployment descriptor. Try typing one of those out by hand sometime: it truly sucks.
(on preview: what robinw said, but I disagree. Seems like a perfectly valid design choice to me)
posted by sbutler at 1:04 PM on December 29, 2004
<key>some key</key>instead of something more verbose, like
<string>some value</key>
<entry>But I don't remember anything in the XML spec that says sibling order can be ignored -- so Apple is completely within its right. I rather like the more compact way they did it.
<key>some key</key>
<string>some value</key>
</entry>
incidentally, Sun went the verbose route with Servlets/JSP and the deployment descriptor. Try typing one of those out by hand sometime: it truly sucks.
(on preview: what robinw said, but I disagree. Seems like a perfectly valid design choice to me)
posted by sbutler at 1:04 PM on December 29, 2004
ermm.. foiled again by copy and paste! please excuse my obviously invalid XML
posted by sbutler at 1:05 PM on December 29, 2004
posted by sbutler at 1:05 PM on December 29, 2004
oh, ok.
you could probably write an xslt transform that collects together key/value pairs and inserts an extra element round them. then filter your data through that. or parse with a stream interface (sax), which makes changing state in this way fairly simple.
imho, this is a problem because tools don't use the dtd sufficiently. if you look at the dtd, the structure is pretty obvious (it's an elegant recursive definition, just like you'd write in a functional language).
posted by andrew cooke at 1:13 PM on December 29, 2004
you could probably write an xslt transform that collects together key/value pairs and inserts an extra element round them. then filter your data through that. or parse with a stream interface (sax), which makes changing state in this way fairly simple.
imho, this is a problem because tools don't use the dtd sufficiently. if you look at the dtd, the structure is pretty obvious (it's an elegant recursive definition, just like you'd write in a functional language).
posted by andrew cooke at 1:13 PM on December 29, 2004
(in fact, you might find that a fancy xml parser for (extended) haskell generates data structures from that dtd just like you'd write yourself.)
posted by andrew cooke at 1:15 PM on December 29, 2004
posted by andrew cooke at 1:15 PM on December 29, 2004
generates data structures -> generates types and code (to generate typed structures from the xml)
posted by andrew cooke at 1:17 PM on December 29, 2004
posted by andrew cooke at 1:17 PM on December 29, 2004
The only way to find out when the current key/value pair ends is by the next node having another key.
Huh? It's a pair. <!ELEMENT dict (key, %plistObject;)*>. Man, or machine, can use XSL's following-sibling selector to easily parse and transform plists.
posted by nicwolff at 1:26 PM on December 29, 2004
Huh? It's a pair. <!ELEMENT dict (key, %plistObject;)*>. Man, or machine, can use XSL's following-sibling selector to easily parse and transform plists.
posted by nicwolff at 1:26 PM on December 29, 2004
Not to snark, but I knew little about XSL and DTDs and nothing about XSL before I googled "plist xml" after reading your question. So, I thank you for the opportunity to educate myself but my clients hate us both now for the work time lost...
posted by nicwolff at 2:04 PM on December 29, 2004
posted by nicwolff at 2:04 PM on December 29, 2004
Oh, wait, you thought it was "pflist" - it's "plist" - never mind, you wouldn't have found it.
posted by nicwolff at 2:05 PM on December 29, 2004
posted by nicwolff at 2:05 PM on December 29, 2004
This thread is closed to new comments.
posted by andrew cooke at 12:40 PM on December 29, 2004